feat!: no_from by Thunkar · Pull Request #21716 · AztecProtocol/aztec-packages

Thunkar · 2026-03-18T06:13:37Z

Getting rid of the tyranny of the Account entrypoint, and the terrible sentinel value of AztecAddress.ZERO in the from parameter.

Now, when a tx is specified as being sent from: NO_FROM, the wallet completely bypasses the account contract. It doesn't even use the MulticallEntrypoint contract, it'll just execute a single call using DefaultEntrypoint. Since we can do wrapping at the app level, this means ANYTHING goes. Want to wrap 10 calls on a special sauce multicall? Go ahead. App-sponsored FPC with custom logic that must be the first on the chain? Knock yourself out!

Even better news: this is thoroughly tested in our codebase thanks to account contract self-deployments. They're a great example of "I don't want to use an account contract as entrypoint" flow.

As an extra side effect, this completely deshrines the MulticallEntrypoint protocol contract from the wallet (we only have the convenience now of it being already registered in every single wallet)

…packages into gj/gas_estimations_on_send

…packages into gj/no_from

yarn-project/aztec.js/src/contract/contract_function_interaction.ts

yarn-project/aztec.js/src/authorization/call_authorization_request.ts

mverzilli · 2026-03-18T10:16:24Z

boxes/boxes/vanilla/app/embedded-wallet.ts


    const deployOpts: DeployAccountOptions<InteractionWaitOptions> = {
-      from: AztecAddress.ZERO,
+      from: NO_FROM,


NO_FROM sounds so strange, isn't there some other way to name this hinting at its effects? maybe something like PAYLOAD_DEFINED_FROM (which is probably wronger and horribler, but I'm trying to convey my objection)

seeing the changes to the docs, maybe CREATED_BY_TX

Not in love with the naming too, I went for parallelism with NO_WAIT...

It is weird, yes, but I'm also having trouble coming up with something better. Perhaps from: DIRECT_CALL? idk

I agree that NO_FROM sounds strange. Now that Claude is back up, it suggested a few options:

DIRECT or DIRECT_EXECUTION -- signals that the tx bypasses the account contract entrypoint

NO_ACCOUNT -- clearer that you're opting out of account contract wrapping

RAW -- short, implies no wrapping/mediation

SELF -- the transaction acts on its own behalf without an intermediary account contract

UNMEDIATED -- explicitly says "no account contract mediation"

ENTRYPOINTLESS -- describes the mechanism being skipped (the account entrypoint)

NO_SENDER -- closer to the domain: there's no "sender" account wrapping the call

And it even provided a ranking 😅

My ranking would be: DIRECT > NO_ACCOUNT > NO_SENDER > SELF > UNMEDIATED > ENTRYPOINTLESS > RAW > NO_FROM.

Sorry but all of those are worse IMO xD

from is pretty generic, it has no concept of account (wallet just happens to make it so from is an account, but we had the exception of the multicall entrypoint...which is not one). The NO_WAIT parallel is also a pro in my book

mverzilli · 2026-03-18T10:59:28Z

yarn-project/end-to-end/src/test-wallet/test_wallet.ts

+    let overrides: SimulationOverrides | undefined;
+    let txRequest: TxExecutionRequest;
+    if (from === NO_FROM) {
+      const entrypoint = new DefaultEntrypoint();
+      txRequest = await entrypoint.createTxExecutionRequest(finalExecutionPayload, feeOptions.gasSettings, chainInfo);
+    } else {
+      const useOverride = this.simulationMode === 'kernelless-override';
+      let fromAccount: Account;
+      if (useOverride) {
+        const { account, instance, artifact } = await this.getFakeAccountDataFor(from);
+        fromAccount = account;
+        overrides = {
+          contracts: { [from.toString()]: { instance, artifact } },
+        };
+      } else {
+        fromAccount = await this.getAccountFromAddress(from);
+      }
+      const executionOptions: DefaultAccountEntrypointOptions = {
+        txNonce: Fr.random(),
+        cancellable: this.cancellableTransactions,
+        feePaymentMethodOptions: feeOptions.accountFeePaymentMethodOptions,
+      };
+      txRequest = await fromAccount.createTxExecutionRequest(
+        finalExecutionPayload,
+        feeOptions.gasSettings,
+        chainInfo,
+        executionOptions,
+      );
+    }


suggestion: extract this to an aux function that gives you { txRequest, overrides } so we can use early returns and avoid the fat else branch

Since this is in itself a helper, I didn't want to muddy the waters further...I think it conveys "bare entrypoint vs. account contract well". But maybe I'm just too brain damaged by now

mverzilli

This makes a ton of sense and the implementation looks solid, my only concern is with NO_FROM naming given it's gonna be public API. I don't have a strong enough alternative I can propose so approving, maybe I would run this through people with a less close perspective of the codebase (eg devrel, Wonder, Ciara, etc)

…packages into gj/no_from

nventuro · 2026-03-18T13:08:32Z

boxes/boxes/vanilla/app/embedded-wallet.ts


    const deployOpts: DeployAccountOptions<InteractionWaitOptions> = {
-      from: AztecAddress.ZERO,
+      from: NO_FROM,


It is weird, yes, but I'm also having trouble coming up with something better. Perhaps from: DIRECT_CALL? idk

docs/docs-developers/docs/aztec-js/how_to_create_account.md

nventuro · 2026-03-18T13:14:16Z

docs/examples/ts/recursive_verification/index.ts

+  console.error(
+    "data.json not found. Run 'yarn data' first to generate proof data.",
+  );


Is your formatter configured to fewer than 120 chars?

the doc examples are...weird. I cannot get the ts server to behave with them and editing them does whatever. They also take forever to build...we have to talk to devrel about this

yarn-project/aztec.js/src/contract/contract_function_interaction.ts

yarn-project/aztec.js/src/contract/interaction_options.ts

nventuro · 2026-03-18T13:20:19Z

yarn-project/aztec.js/src/wallet/deploy_account_method.ts

+      // Account contracts are always universally deployed (deployer = ZERO),
+      // but we still need to know the original `from` to detect self-deployment.


Why are they always universally deplyoed?

Convention. Nothing prevents us from doing it differently

nchamo

Great work!

yarn-project/aztec.js/src/api/account.ts

yarn-project/wallet-sdk/src/base-wallet/base_wallet.ts

AztecBot · 2026-03-18T20:54:43Z

❌ Failed to cherry-pick to v4-next due to conflicts. (🤖) View backport run.

… call The no_from PR (#21716) changed how AztecAddress.ZERO is handled in the embedded wallet simulate path. The simulate call in setupAccountWithPrivateKey was using AztecAddress.ZERO as the from address, which now causes the wallet to attempt looking up account data for the zero address (which doesn't exist). Changed to use NO_FROM which is the correct API for opting out of account contract mediation during simulation.

…#21402) ## Summary The `feat!: no_from` PR (#21716) changed how `AztecAddress.ZERO` is handled in the embedded wallet's simulate path. `BotFactory.setupAccountWithPrivateKey` was passing `AztecAddress.ZERO` as the `from` address in the `simulate` call, which now causes the wallet to attempt looking up account data for the zero address — resulting in `"Account 0x000...000 does not exist on this wallet"`. Fixed by using `NO_FROM` (already imported and used in the adjacent `send` call) which is the correct API for opting out of account contract mediation during simulation. ## Failing tests fixed - `e2e_bot › bridge resume › reuses prior bridge claims` - `e2e_bot › bridge resume › does not reuse prior bridge claims if recipient address changes` - `e2e_bot › setup via bridging funds cross-chain › creates bot after inbox drift` ## Test plan - All 10 e2e_bot tests pass locally (previously 3 were failing) ClaudeBox log: https://claudebox.work/s/11a8e25f0aefa248?run=1

## Summary Backports #21716 to v4-next via `backport-to-v4-next-staging`. Based on latest `backport-to-v4-next-staging` which has #21646 (gas estimations on send), so this PR contains only #21716's actual changes (NO_FROM pattern). Cherry-pick conflicts resolved: - `bot/src/factory.ts` — `AztecAddress.ZERO` → `NO_FROM` - `e2e_fees/account_init.test.ts` — `AztecAddress.ZERO` → `NO_FROM` - `docs/examples/ts/recursive_verification/index.ts` — imports + data loading updated - `docs/examples/ts/aztecjs_connection/index.ts` — `AztecAddress.ZERO` → `NO_FROM` in existing fee juice section, discarded duplicate sections from cherry-pick - `spartan/block_capacity.test.ts` — deleted (already removed on v4-next) ## Key changes - Introduces `NO_FROM` pattern replacing `AztecAddress.ZERO` sentinel for bypassing account contract entrypoint - Removes `SignerlessAccountContract` - Uses `DefaultEntrypoint` directly when `from: NO_FROM` - Deshrines `MulticallEntrypoint` from wallet internals --------- Co-authored-by: Gregorio Juliana <gregojquiros@gmail.com>

Thunkar added 16 commits March 16, 2026 11:13

wip

a8893ac

Merge branch 'merge-train/fairies' of github.com:AztecProtocol/aztec-…

4a235c6

…packages into gj/gas_estimations_on_send

wip

5155d65

fix

cd90ea3

tighter padding

999ec45

comment

91f55e3

default padding

0bcd34c

respect user provided gas limits

9a6a4d8

comments from review

64cd6b3

better comment

cf97030

typo

f75c2db

fixed simu simu toggle

e31d5e3

testwallet modes

457dd71

wip

05af60e

Merge branch 'merge-train/fairies' of github.com:AztecProtocol/aztec-…

f07b83e

…packages into gj/no_from

wip

e143a94

Thunkar added the ci-draft Run CI on draft PRs. label Mar 18, 2026

Thunkar added 2 commits March 18, 2026 06:30

fix

dff80ba

remove aztecaddress zero

edfcf13

Thunkar added the ci-no-fail-fast Sets NO_FAIL_FAST in the CI so the run is not aborted on the first failure label Mar 18, 2026

Thunkar added 5 commits March 18, 2026 07:02

removed result nesting

d3328b4

fixed test

0401e9e

better test

0b6172f

migration notes

6518c30

revert some changes to deployments

87d9e73

Thunkar commented Mar 18, 2026

View reviewed changes

yarn-project/aztec.js/src/contract/contract_function_interaction.ts Outdated Show resolved Hide resolved

Thunkar commented Mar 18, 2026

View reviewed changes

yarn-project/aztec.js/src/authorization/call_authorization_request.ts Show resolved Hide resolved

Thunkar marked this pull request as ready for review March 18, 2026 09:00

Thunkar requested review from a team and nventuro as code owners March 18, 2026 09:00

Thunkar requested review from mverzilli and nchamo March 18, 2026 09:48

mverzilli reviewed Mar 18, 2026

View reviewed changes

mverzilli approved these changes Mar 18, 2026

View reviewed changes

Merge branch 'merge-train/fairies' of github.com:AztecProtocol/aztec-…

08f5ac6

…packages into gj/no_from

nventuro reviewed Mar 18, 2026

View reviewed changes

Thunkar added 2 commits March 18, 2026 13:38

comments from review

575de76

coments from review

e95719d

Thunkar added the backport-to-v4-next label Mar 18, 2026

nchamo approved these changes Mar 18, 2026

View reviewed changes

yarn-project/aztec.js/src/api/account.ts Outdated Show resolved Hide resolved

yarn-project/wallet-sdk/src/base-wallet/base_wallet.ts Outdated Show resolved Hide resolved

Thunkar added 2 commits March 18, 2026 20:07

comments from review

6932570

fixes

b6c4b8e

Thunkar merged commit 2257864 into merge-train/fairies Mar 18, 2026
11 checks passed

Thunkar deleted the gj/no_from branch March 18, 2026 20:53

AztecBot pushed a commit that referenced this pull request Mar 18, 2026

cherry-pick: feat!: no_from (#21716) — with conflicts

902f22f

AztecBot added a commit that referenced this pull request Mar 18, 2026

fix: resolve cherry-pick conflicts for feat!: no_from (#21716)

7ff646c

This was referenced Mar 18, 2026

chore: backport PR #21716 (feat!: no_from) to v4-next #21768

Merged

feat: merge-train/fairies #21760

Open

AztecBot pushed a commit that referenced this pull request Mar 18, 2026

cherry-pick: feat!: no_from (#21716) — with conflicts

fbfd820

AztecBot added a commit that referenced this pull request Mar 18, 2026

fix: resolve cherry-pick conflicts for feat!: no_from (#21716)

f12826c

AztecBot mentioned this pull request Mar 19, 2026

fix(bot): use NO_FROM instead of AztecAddress.ZERO in deploy simulate #21402

Merged

AztecBot pushed a commit that referenced this pull request Mar 19, 2026

cherry-pick: feat!: no_from (#21716) — with conflicts

849d6b6

AztecBot added a commit that referenced this pull request Mar 19, 2026

fix: resolve cherry-pick conflicts for feat!: no_from (#21716)

1249867

		// Account contracts are always universally deployed (deployer = ZERO),
		// but we still need to know the original `from` to detect self-deployment.

Conversation

Thunkar commented Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mverzilli left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nchamo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

AztecBot commented Mar 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Thunkar commented Mar 18, 2026 •

edited

Loading